home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000524_timbl@www3.cern.ch _Fri Jan 8 17:27:37 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  9KB
  1. Return-Path: <timbl@www3.cern.ch>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA00654; Fri, 8 Jan 93 17:27:37 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA24708; Fri, 8 Jan 1993 17:42:37 +0100
  6. Received: by www3.cern.ch (NX5.67c/NX3.0S)
  7.     id AA03067; Fri, 8 Jan 93 17:42:32 +0100
  8. Date: Fri, 8 Jan 93 17:42:32 +0100
  9. From: Tim Berners-Lee <timbl@www3.cern.ch>
  10. Message-Id: <9301081642.AA03067@www3.cern.ch>
  11. Received: by NeXT.Mailer (1.87.1)
  12. Received: by NeXT Mailer (1.87.1)
  13. To: Dave_Raggett <dsr@hplb.hpl.hp.com>
  14. Subject: HTTP2: caching and copyright
  15. Cc: www-talk@nxoc01.cern.ch
  16. Reply-To: timbl@nxoc01.cern.ch
  17.  
  18. These are comment son the second part of Dave's note.
  19. They refer to the new HTTP spec and a hypertextversion of RFC850  which I made
  20. in order to be able to cross-reference to it (and make it prettier).
  21.  
  22. >  Caching
  23. >  -------
  24. >  
  25.  
  26. >  It will be desirable to avoid overloading servers with popular documents by
  27. >  supporting a caching scheme at local servers (or even at browsers?). This
  28. >  implies that document headers should provide sufficient information to make
  29. >  this practical.
  30.  
  31. Like "Expires:" for example. See
  32. http://info.cern.chhypertext/WWW/Protocols/HTTP/Object_Headers.html
  33.  
  34. ...>  
  35.  
  36. >      o   the document header should *always* include a "Date:" field giving
  37. >          the date it was last written to
  38.  
  39. Agreed.  Now why in the spec did I say that Date: was the creation date?
  40. In any event, we need last-modified as well as created dates. I chose
  41. to use the existing Date: field of RFC 850 as the creation date.
  42. I guess the modified date is more available, but if you are tracing things
  43. the creation date is a better thing to file under.  For a mail/news article
  44. of course they are the same.
  45.  
  46. >      o   the "Expires:" field is optional
  47.  
  48. agreed.
  49.  
  50. >      o   the date values should be in a prescribed format to simplify
  51. >          machine interpretation (Is this adequately defined by existing  
  52. RFCs?)
  53.  
  54. agreed. yes it is, in RFC850: in 
  55.  
  56. http://info.cern.ch/hypertext/WWW/Protocols/rfc850/rfc850.html#z10
  57.   
  58.  
  59.   (pretty soon we're going to HAVE to have hypertext mail!).
  60.   
  61.  
  62. >  I think that we need to provide an operation in which the server returns a
  63. >  document only if it is later that a date/time supplied with  the request. If
  64. >  it is the same (or earlier) the server should return a suitable status code
  65. >  and an optional "Cost:" header, see below.
  66.  
  67. Need to look at NNTP here.  We end up getting very close indeed to it.
  68. I would want the functionalty of this search to map onto the NEWNEWS
  69. very nicely.  A newsgroup is just a hypertext list anyway.
  70.  
  71. >  Note that servers shouln't cache documents with restricted readership since
  72. >  each server don't know the restrictions to apply. This requires a further
  73. >  header to identify such documents as being unsuitable for general caching:
  74. >  
  75.  
  76. >      Distribution: restricted | unrestricted
  77.  
  78. Good point.  Not the the distribution of other messages is in the form of
  79. To: and Cc: and Newsgroup: and in fact Distribution:.  (See  
  80. http://info.cern.ch/hypertext/WWW/Protocols/rfc850/rfc850.html#z12)
  81. So you'll need a new fieldname.  If we could only merge the functionality of  
  82. these systems in some cool way, it would be grand.
  83.  
  84. When looking at protection for more than just GET, I came up with the
  85.     Public: *<method>
  86.     Allow: *<method>
  87. lines documented in the list of object headers I mentioned above.
  88.  
  89. >  This header is only needed for documents with restricted readership.
  90. >  An dirty alternative would be to set the expiry date to the same value as
  91. >  supplied with the "Date:" header.
  92.  
  93. Yes but that would not be legally binding.  It could also mean "this document  
  94. is a live status: fetch it as often as you can".
  95.  
  96. >  Copyright & Payments
  97. >  --------------------
  98. >  
  99.  
  100. >  Although the Internet backbone restricts profit making services, many  
  101. subnets,
  102. >  such as University campuses, and company subnets such as HP's have no such
  103. >  problem. Indeed users strongly want access to copyrighted information for
  104. >  which a payment is due.
  105. >  
  106.  
  107. >  My suggestion is that servers are responsible for tracking who accesses what
  108. >  information, and hence how much they owe. For use within Hewlett Packard for
  109. >  library services, we anticipate including some extra headers in the request:
  110. >  
  111.  
  112. >      EmployeeNumber: 148689
  113. >      LocationCode:   8126        (an account number for cross charging)
  114. >  
  115.  
  116. >  This would be stripped off when sending requests to servers outside the HP
  117. >  subnet. These headers are ignored by servers which conform to strict HTPP2.
  118. >  
  119.  
  120. >  I would like the document header to include an optional cost header, e.g.
  121. >  
  122.  
  123. >      Cost: 4.05 US DOLLARS
  124. >      Copyright: Reuters Inc.
  125.  
  126. I note here that both the copyright holder and the account for charging are  
  127. items in some address space, and we ought to be as flexible with these address  
  128. spaces as wit the udi.  So I would propose something like
  129.  
  130.     ChargeTo:  HPInternal:/8126/148689  upto $2.00
  131.     
  132. would be better.  But how does this fit in with authentication?  Once you are
  133. authenticated, your prefered method of paying will be known.  You can't have
  134. charging without authentication!
  135.  
  136. There is a little problem with sending an "upto $2.00" field as it requires  
  137. honesty of the server not to just charge you $2.00 flat!  This is a real  
  138. problem, as otherwise one needs twice the round trip delays, which we really  
  139. object to, if one prefers the fairer
  140.  
  141.     C    GET  junk
  142.     S    No way: you pay $2.00 first
  143.     C    GET junk I promise to pay $2.00
  144.     S    *junk
  145.  
  146.  
  147. >  This would let the users know how much a given document has cost them, as  
  148. well
  149. >  as who owns the copyright. The latter heading is needed since you can't  
  150. always
  151. >  put it in the document, e.g. think of photographic images.
  152. >  
  153.  
  154. >  
  155.  
  156. >  The "Cost: 4.03 US DOLLARS" field
  157. >  
  158.  
  159. >  
  160.  
  161. >  Copyright and Caching
  162. >  ---------------------
  163. >
  164.  
  165. Have you read "Litterary Machines?" That goes into this in a lot of detail,
  166. or at least Xanadu should have done.
  167.  
  168. >  What happens if a copyright protected document is saved in the cache of a
  169. >  local server? We have got to ensure that the rightful owners get paid for
  170. >  access even when the document is obtained from a local server's cache.
  171. >  
  172.  
  173. >  My idea is that for each access, this server should inform the server on  
  174. which
  175. >  the original document resides. 
  176.  
  177.  
  178. yes -- hence we need three classes, free, forpay, restricted.  I wonder whwther  
  179. these were Brewster's 3 types of flag in his proposed WAIS udi.
  180.  
  181. >  The protocol ought to allow for multiple GOT statements (and associated
  182. >  headers in the same message. For this it seems simple enough to require a
  183. >  terminating blank line.
  184.  
  185. Hey, that;s not something you do for one method, it's a change to the whole  
  186. protocol to introduce pipelining.
  187.  
  188. A simple thing in the first instance is to say that it illegal to cache
  189. a for-pay document unless you have a privat earrangement with the owner
  190. about refunding him.  This could be done using a completely separate billing  
  191. process.
  192.  
  193.  
  194. >  Naming Parts of a Multipart body
  195. >  --------------------------------
  196. >  
  197.  
  198. >  It would be nice to use the MIME format's capability to send multiple
  199. >  documents as part of the same message, e.g. an HTML doc with several
  200. >  pictures. To make this work each separate part needs to include the
  201. >  Document Udi in its header, so that the browser can check if it has the
  202. >  document in its local cache (history stack) or whether it needs to make
  203. >  network request for the picture etc.
  204. >  
  205.  
  206. >      DocumentName: Udi
  207.  
  208. Sure.  This is a very useful thing to put in a mail message anyway.
  209. Like
  210.  
  211. Archived-as:
  212. or
  213. Available:
  214.  
  215. >  Effective support for discussion groups
  216. >  ---------------------------------------
  217. >  
  218.  
  219. >  My model is that discussion groups each have unique Udi's. Each discussion
  220. >  group has a sequence of base notes, and each base note is associated with a
  221. >  sequence of responses. I am unsure of how to deal with cross postings!
  222.  
  223. I agree that the POST method is well defined as a method of the
  224. newsgroup class which takes an article as a parameter. In fact, as you say,
  225. cross-posting makes a mess of this, as it involved many groups in one atomic  
  226. operation.  This is a peculiarity of news which makes it difficult to map onto  
  227. the object model.  Any ideas?
  228.  
  229. ...
  230. >  You also need a way of retrieving a given response. One way is to ask for  
  231. the
  232. >  list of Udi's for all the responses,
  233.  
  234. Yes.
  235.  
  236. > another is a command to get a particular
  237. >  response given the Udi for the base note and a sequence number, e.g.
  238.  
  239. No -- not sufficiently stateless.
  240.  
  241. >  I assume the POST command can be accompanied by an html doc as a body.
  242.  
  243. yes
  244.  
  245. >  Looking forward to your comments,
  246. >  
  247.  
  248. >  David Raggett
  249.  
  250. as you see mine got shorter with time...
  251.  
  252. tim
  253.